I tried multiple approachs here to do the arity/bound check, and i think this is the best option.

the other options i tried, but did not work:

1. pack the arity byte into a spare slot in ZEND_INIT_FCALL / ZEND_NEW: this was the original plan, and it was the main reason why the 255 cap limit on the generic paraemters was introduced ( although, kept because its good to have anyway ), however, the full 32 bit operand on those opcodes is consumed by the value-arg count, narrowing it to 24 bits would have given us a byte for the generic arity, but that would be a BC break i assume ( even if no one is realistically calling a function with over 16 million params ).
2. side table per call frame: keyed off a flag on zend_function, measurable regression on the bench suite ( Zend/bench.php - ~1.8% ) from a cold-cacheline read on every call
3. A fn_flags bit: same idea as 2, smaller but still measurable regression ( ~1.2 ) because the bit is read on every call regardless of turbofish use.

so a dedicated opcode emitted only at turbofish sites is the "simplest" approach here, and does not effect performance.

the substitution sites for inherited members (this one, do_inherit_property, the property hook signatures it walks, zend_do_traits_property_binding, zend_add_trait_method) all follow the same pattern: clone the parent's zend_property_info or zend_function, allocate a fresh arg_info block in the child's arena, share the body opcodes via the existing refcount mechanism. Body opcodes are not re-emitted per child.

the cost is a documented runtime laxity: the body's VERIFY_* opcodes were laid down at the parent's compile time against the parent's unsubstituted view, so the child sees the substituted signature on the clone but the original opcodes inside.

The alternative would be bridge methods that re-verify the substituted return type before calling the shared body, which costs a permanent per-substitution call-frame on every inherited method invocation.

future work (body-level monomorphization) can close this gap.

see:

• https://stackoverflow.com/questions/5007357/java-generics-bridge-method
• https://angelikalanger.com/GenericsFAQ/FAQSections/TechnicalDetails.html#FAQ102

zend_check_generic_link_bounds validates each supplied arg against the corresponding target parameter's bound. It has a special case for forwarded class-scope T refs: when the supplied arg is a leaf class-scope T ref of the inheriting class, the effective arg type is the inheriting class's own bound on that parameter, the check becomes "ce's bound on Y must satisfy target's bound on T".

The reading is strict: if ce has no bound on Y (the parameter is unbounded, hence mixed), the check fails for any target bound stricter than mixed. An unbounded child parameter cannot be forwarded into a bounded ancestor slot.

The relaxed alternative would be to let an unbounded child parameter inherit the parent's bound implicitly when forwarded. Implicit inheritance of bounds across class boundaries is harder to model both for the compiler and for human readers, and yields a worse error message when the user forgets to write a bound they meant to write.

e.g:

class A<T: string|int|float> {}

class B<Y> extends A<Y> {}

strict: fail "mixed vs string|int|float"
relaxed: allow, Y is now implicitly bound to string|int|float

zend_try_inline_call inlines simple function calls by replacing their INIT_FCALL and DO_FCALL opcodes with NOP.

e.g. before the optimizer:

INIT_FCALL                ; allocates the call frame
VERIFY_GENERIC_ARGUMENTS  ; reads EX(call)->func
DO_FCALL

after inlining without the guard:

NOP                       ; frame never set up
VERIFY_GENERIC_ARGUMENTS  ; EX(call)->func walks an unrelated frame causing segfault
NOP

The constraint is permanent: any future pass that elides an INIT_FCALL/DO_FCALL pair has to consider whether intervening opcodes depend on the call frame.